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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the stage 2 of the UE Positioning (UP) function of UTRAN, which provides the 
mechanisms to support the calculation of the geographical location of a UE. UE position knowledge can be used for 
example in support of Radio Resource Management functions, location based services for operators, subscribers and 
third party service providers. The purpose of this stage2 specification is to define the UTRAN UP architecture, 
functional entities and operations to support positioning methods. This description is confined to the UTRAN Access 
Stratum. It does not define nor describe how the results of the UE position calculation can be utilised in the Core 
Network e.g. LCS or in UTRAN e.g. RRM. 

UP may be considered as a network provided enabling technology consisting of standardised service capabilities, which 
enable the provision of location applications. The application(s) may be service provider specific. The description of the 
numerous and varied possible location applications which are enabled by this technology are outside the scope of the 
present document. However, clarifying examples of how the functionality being described may be used to provide 
specific location services may be included. 

This stage 2 specification covers the UTRAN UP functional model and entities, the positioning methods, state 
descriptions, and message flows. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

2.1 Normative references 

[I] 3GPP TS 23.171: "Functional stage 2 description of location services in UMTS". 

[2] 3GPP TS 01.04: "Digital cellular telecommunication system (Phase 2+); Abbreviations and 

acronyms". 

[3] Technical Specification Group Services and System Aspects Service aspects; Terminology and 

Vocabulary within TSG-Sl: Report and Recommendations, 28.7.99. 

[4] 3GPP TS 02.71: "Digital cellular telecommunications system (Phase 2+); Location Services 

(LCS); Service description. Stage 1". 

[5] 3GPP TS 03.71: "Digital cellular telecommunications system (Phase 2+); Location Services 

(LCS); (Functional description) - Stage 2". 

[6] 3GPP TS 03.32: "Universal Geographical Area Description". 

[7] 3GPP TS 22.100: "UMTS phase 1 Release 99". 

[8] 3GPP TS 22.101: "Service principles". 

[9] 3GPP TS 22.105: "Services and Service Capabilities". 

[10] 3GPPTS 22.115: "Charging and Billing". 

[II] 3GPP TS 22.121: "The Virtual Home Environment". 

[12] 3GPP TS 23.1 10: "UMTS Access Stratum; Services and Functions". 
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[13] 3GPP TS 25.413: "UTRAN lu interface RANAP signalling". 

[14] 3GPP TS 25.423: "UTRAN lur interface RNSAP signalling". 

[15] 3GPP TS 25.433: "UTRAN lub interface NBAP signalling". 

[16] 3GPP TS 25.214: "Physical layer procedures (FDD)" 

[17] 3GPP TS 25.215: "Physical layer - Measurements (FDD)". 

[18] 3GPP TS 25.225: "Physical layer - Measurements (TDD)". 

[19] 3GPP TS 25.331: "RRC protocol specification". 

[20] 3GPP TS 23.032: "Universal Geographical Description (GAD)". 

[21] 3GPP TS 25.430: "UTRAN lub interface: General aspects and Principles". 

[22] 3GPP TS 23.171: "Functional stage 2 description of location services in UMTS". 

2.2 Informative references 

[23] Third generation (3G) mobile communication system; Technical study report on the location 

services and technologies, ARIB ST9 December 1998. 

[24] The North American Interest Group of the GSM MoU ASSOCIATION: Location Based Services, 

Service Requirements Document of the Services Working Group. 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TS 22.101 and some of the terms 
and definitions in annex A apply. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply. 

3G-MSC 3'*^ Generation MSC 

3G-SGSN 3"^'' Generation SGSN 

ARIB Association of Radio Industries and Business 

ATD Absolute Time Difference 

CAMEL Customised Application For Mobile Network Enhanced Logic 

CN Core Network 

CRNC Controlling RNC 

DL Downlink 

DRNC Drift RNC 

GMLC Gateway MLC 

GPRS General Packet Radio System 

GPS Global Positioning System 

HLR Home Location Register 

IPDL Idle Period Downlink 

LBS Location Based Services 

LCCF Location Client Control Function 

LCF Location Client Function 

LCS Location Services 

LMU Location Measurement Unit 

LSCF Location System Control Function 
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LSOF Location System Operation Function 

MLC Mobile Location Centre 

MSC Mobile services Switching Centre 

OTDOA Observed Time Difference Of Arrival 

PCF Position Calculation Function 

PLMN Public Land Mobile Network 

PRCF Positioning Radio Co-ordination Function 

PRRM Positioning Radio Resource Management 

PSMF Positioning Signal Measurement Function 

QoS Quality of Service 

RAN Radio Access Network 

RANAP Radio Access Network Application Part 

RNC Radio Network Controller 

RRM Radio Resource Management 

RTD Real Time Difference 

RTT Round Trip Time 

SAI Service Area Identifier 

SGSN Serving GPRS Support Node 

SIM Subscriber Identity Module 

SMLC Serving MLC 

SMS Short Message Service 

SRNC Serving RNC 

SSDT Site Selection Diversity Transmit 

TOA Time Of Arrival 

U- UMTS-(LCS functional block) 

UE User Equipment 

UL Uplink 

UMTS Universal Mobile Telecommunication System 

UP UE Positioning 

USIM User Service Identity Module 

UTC Universal Time Coordinates 

UTRAN Universal Terrestrial Radio Access Network 

WCDMA Wideband Code Division Multiple Access 



4 Main concepts and requirements 

A general description of location services and the service requirements is given in [4]. 

By measuring radio signals the capability to determine the geographic position of the UE shall be provided. The 
position information may be requested by and reported to a client (application) associated with the UE, or by a client 
within or attached to the CN. The position information may also be utilised internally by UTRAN, for example, for 
location assisted handover or to support other features such as home location billing. The position information shall be 
reported in standard formats, such as those for cell based or geographical co-ordinates, together with the time-of-day 
and the estimated errors (uncertainty) of the position of the UE. 

It shall be possible for the majority of the UE (active or inactive) within a network to use the feature without 
compromising the radio transmission or signalling capabilities of the UTRAN. 

The uncertainty of the position measurement shall be network implementation dependent at the choice of the network 
operator. The uncertainty may vary between networks as well as from one area within a network to another. The 
uncertainty may be hundreds of metres in some areas and only a few metres in others. In the event that the position 
measurement is also a UE-assisted process, the uncertainty may also depend on the capabilities of the UE. In some 
jurisdictions, there is a regulatory requirement for location service accuracy that is part of an emergency service. Further 
details of the accuracy requirements can be found in [4] . 

The uncertainty of the position information is dependent on the method used, the position of the UE within the coverage 
area and the activity of the UE. Several design options of the UTRAN system (e.g. size of cell, adaptive antenna 
technique, path loss estimation, timing accuracy. Node B surveys) shall allow the network operator to choose a suitable 
and cost effective UP method for their market. 
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There are many different possible uses for the positioning information. The positioning functions may be used internally 
by the UTRAN, by value-added network services, by the UE itself or through the network, and by "third party" 
services. The feature may also be used by an emergency service (which may be mandated or "value-added"), but the 
location service is not exclusively for emergencies. 

The UTRAN is a new radio system design without a pre-existing deployment of UE operating according to the radio 
interface. This freedom from legacy equipment enables the location service feature design to make use of appropriate 
techniques to provide the most accurate results. The technique must also be a cost-effective total solution, must allow 
evolution to meet evolving service requirements and be able to take advantage of advances in technology over the 
lifetime of UTRAN deployments. 

4.1 Assumptions 

As a basis for the operation of UP in UTRAN the following assumptions apply: 

the UE shall support SFN-SFN observed time difference type 2 measurements, thus support of Network-based 
OTDOA without idle periods is mandatory in the UE. 

- both TDD and FDD will be supported in release '99; 

the provision of the UP function in UTRAN is optional through support of the specified method(s) in Node B 
and the RNC; 

UP is applicable to any target UE whether or not the UE supports LCS, but with restrictions on use of certain 
positioning method depending on UE capability as defined in 25.926; 

RNC contains SMLC functionality and UP information is transported between RNCs via the lur interface; 

the positioning information may be used for internal system operations to improve system performance; 

different types of LMU are defined, e.g. a standalone LMU and/or LMU integrated in Node B; 

the UP architecture and functions shall include the option to accommodate several techniques of measurement 
and processing to ensure evolution to follow changing service requirements and to take advantage of advancing 
technology. 



4.2 UE Positioning IVIethods 



The UTRAN may utilise one or more positioning methods in order to determine the position of an UE. Positioning the 
UE involves two main steps: 

signal measurements; and 

Position estimate computation based on the measurements. 

The signal measurements may be made by the UE, the Node B or a LMU. The basic signals measured are typically the 
UTRA radio transmissions, however, some methods may make use of other transmissions such as general radio 
navigation signals. 

In addition the positioning function should not be limited to a single method or measurement. That is, it should be 
capable of utilising other standard methods and measurements, as are available and appropriate, to meet the required 
service needs of the location service client. This additional information could consist of readily available UTRAN 
measurements such as RTT in FDD or Rx Timing deviation measurement and knowledge of the UE timing advance, in 
TDD. 

The position estimate computation may be made by the UE or by the UTRAN. 
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4.3 Standard UP Methods 

The standard positioning methods supported within UTRAN are: 

cell ID based method; 

OTDOA method that may be assisted by network configurable idle periods (the idle period configurability is to 
be specified in the specification); 

- network-assisted GPS methods. 

4.3.1 Cell ID Based Method 

In the cell ID based (i.e. cell coverage) method, the position of an UE is estimated with the knowledge of its serving 
Node B. The information about the serving Node B and cell may be obtained by paging, locating area update, cell 
update, URA update, or routing area update. 

The cell coverage based positioning information can be indicated as the Cell Identity of the used cell, the Service Area 
Identity or as the geographical co-ordinates of a position related to the serving cell. The position information shall 
include a QoS estimate (e.g. regarding achieved accuracy). 

When geographical co-ordinates are used as the position information, the estimated position of the UE can be a fixed 
geographical position within the serving cell (e.g. position of the serving Node B), the geographical centre of the 
serving cell coverage area, or some other fixed position within the cell coverage area. The geographical position can 
also be obtained by combining information on the cell specific fixed geographical position with some other available 
information, such as the signal RTT in FDD ([17]) or Rx Timing deviation measurement ([18]) and knowledge of the 
UE timing advance, in TDD. 

The operation of the cell ID based positioning method is described in clause 8. 

4.3.2 OTDOA-IPDL Method with network configurable idle periods 

The OTDOA-IPDL method involves measurements made by the UE and LMU of the UTRAN frame timing (e.g. SFN- 
SFN observed time difference). These measures are then sent to the SRNC where the position of the UE is calculated. 

The simplest case of OTDOA-IPDL is without idle periods. In this case the method can be referred to as simply 
OTDOA. 

The Node B may provide idle periods in the downlink, in order to potentially improve the hearability of neighbouring 
Node Bs. The support of these idle periods in the UE is optional. Support of idle periods in the UE means that its 
OTDOA performance will improve when idle periods are available. 

Alternatively, the UE may perform the calculation of the location using measurements and assistance data. 

The detailed description of the OTDOA-IPDL positioning method and its operation are described in clause 9. 

4.3.3 Network-assisted GPS Methods 

These methods make use of UEs which are equipped with radio receivers capable of receiving GPS signals. 
The operation of the network-assisted GPS methods is described in clause 10. 



UTRAN UP Architecture 



Figure 5.1 shows the general arrangement of the UE positioning feature in UTRAN. Communication among the 
UTRAN UP entities makes use of the messaging and signalling capabilities of the UTRAN interfaces (lub, lur). 

The SRNC, receives authenticated requests for UE positioning information from the CN across the lu interface. RNCs 
manage the UTRAN resources, including Node Bs, LMUs, the UE and calculation functions, to estimate the position of 
the UE and return the result to the CN. SRNC may also make use of the UP function for internal purpose e.g. position 
based handover. 
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Figure 5.1 : General arrangement of UP in UIVITS 



5.1 UP Operations 



The schematic functional description of LCS operations in UMTS is defined in [1]. 

Upon request from the Core Network or for internal operations, a RNC UP function should: 

- request measurements, typically from the UE and one or more Node B; 

send the measurement results to the appropriate calculating function within UTRAN; 

- receive the result from the calculating function within UTRAN; 

- perform any needed co-ordinate transformations; 

send the results to the LCS entities in the CN or to application entities within UTRAN. 

In the event that the client is internal to UTRAN the request may be made directly to the UTRAN UP entities as the 
internal clients are considered to be "pre-authorised". 

As part of its operation, the UTRAN UP calculating function may require additional information. This may be obtained 
by the function directly by communication with a database, or it may be through a request to UTRAN UP entities that 
will mediate the request and return of information from the appropriate database (or databases if more than one is 
needed to fulfil the requests). 

There may possibly also be available independent information that is able to supply the positioning information directly, 
or may be able to supply auxiliary information to the calculation function. The UTRAN UP co-ordination function, as 
part of its activity to supervise the location process, may query the UE or other elements of the UTRAN to determine 
their capabilities and use this information to select the mode of operation. 

This general operation is outlined in the following (generic) sequence diagram figure 5.2. This figure is not intended to 
show the complete UP operation for UTRAN, but to simply to outline the basis for operation. 
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Figure 5.2: General sequence for UP operation 

5.1 .1 Co-ordination, Measurement and Calculation Functions 

The UTRAN functions for UP provide the co-ordination, measurement and calculation functions needed to provide a 
position estimate. The functions interface with the requesting application and select the appropriate positioning method 
and speed of response. The functions co-ordinate the operations of the radio and measurement equipment to transmit the 
needed signals and to make the needed measurements. The measurements may be made by the Node Bs, or by the 
LMU. The LMU may be associated with the Node B, independently located or remote (i.e. communicating over the Uu 
interface). 

The functions may also access databases or other sources of information appropriate for the positioning method. The 
functions also provide the calculation functions appropriate for the positioning method to estimate the UE position and 
the accuracy of the report. The functions may also make co-ordinates translations to the geographic co-ordinates system 
requested by the application. The functions also may record information on the usage of the UP that may be used for 
administrative purposes (e.g. forwarded to a billing function in the CN). If needed by the positioning method, the 
functions will ensure the broadcast of information and gather and update information concerning UTRAN operating 
parameters (e.g. timing of Node B transmissions) needed for UP operations. 

These entities are mainly concerned with the positioning method, controlling the radio equipment and performing the 
calculations to determine the position and thus may be associated with the RNC in the UTRAN. These functions may 
receive location requests from either the CN or from applications internal to the UTRAN. 

The UTRAN UP entities may also request the subscription and authorisation functions in the CN to authenticate an 
application or a UE subscription or to verify the subscriber privacy parameters. 

The RNC functions communicate with the CN across the lu interface, with other RNC entities across the lur interface 
and with the Node B and LMU across the lub interface and with the UE and the remote LMU across the Uu interface. 

5.2 Functional Description of UTRAN UP related elements 
5.2.1 Radio Network Controller (RNC) 
5.2.1.1 Serving RNC 

The SRNC is a network element of UTRAN and contains functionality required to support LCS in one PLMN. 

The SRNC provides the following functionality: 

- request of information from other RNC: 

The SRNC may request information regarding UP from other RNCs. 
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- broadcast of system information: 

The SRNC may broadcast information in support of the selected positioning method. This broadcast information 
may be specially coded (i.e. encrypted) to ensure its availability only to subscribers of the service. 

The information to be broadcast could include, for example: 

identification and spreading codes of the neighbouring cells (the channels that are used for measurements); 

Relative Time Difference (RTD), i.e. the timing offsets, asynchronicity between base stations, could be based 
on measurement results obtained by LMUs; 

- roundtrip delay estimates in connected mode; 

the geographic location, co-ordinates, of the neighbouring Node B; 

the idle period places within the frame structure for multiple cells; 

the local time-of-day. 

flow control of positioning requests: 

If several simultaneous positioning requests are present within one SRNC, the SRNC co-ordinates the 

positioning requests taking into account priority of the requests (e.g. for Emergency Clients). 

- positioning method selection: 

The positioning method selection is based on the location request, QoS, capabilities of UP elements and UE 
positioning capabilities. 

- position calculation: 

The SRNC may calculate the position of a UE and may also support conversion of the location estimate between 
different geographic reference systems. In case RNC estimates the UE position, it is also responsible to estimate 
the accuracy of the position estimate. This accuracy estimate should include, for example, the effect of geometric 
dilution of precision (GDOP), the capabilities of the signal measuring hardware, the effects of multipath 
propagation and the effects of timing and synchronisation unknowns. The accuracy should be returned as a 
measure of distance in the same units as the location estimate. The accuracy zone may be reported as the axis 
and orientation of an ellipse surrounding the location estimate 

- storage of UP related data: 

The UP related data stored in RNC consists of UE positioning capabilities, data related to clients and 
subscriptions. 

The SRNC, of course, also provides CRNC functionality regarding UP for its associated Node Bs and LMUs. 

5.2.1.2 Other RNC 

5.2.1.2.1 Controlling RNC 

The CRNC provides the following functionality: 

- resources management: 

When allocating resources the CRNC determines which UTRAN elements are involved and what to measure. 
The RNC is also responsible for managing the effect of UP operations on the overall performance of the radio 
network by: 

controlling the variation of the UL and DL signal power level due to UP; 

calculating the DL and UL power/interference due to UP; 

to admit/reject the new positioning requests; 

co-operating with Admission Control, and entities of the RRM (such as power control) to provide the system 
stability in terms of radio resources; 

controlling the IPDL mechanism for OTDOA measurements. This may include the overall control of the 
periodical measurement fulfilment. Co-ordination among RNC (e.g. to assure non-overlapping idle periods) 
will be communicated through the lur interface. 
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- request UP related measurements from its associated Node Bs and LMUs: 

The measurements requested by CRNC from its associated Node Bs and LMUs is dependant on the positioning 
method used. The following measurement returned by a LMU to a CRNC have a general status and may be used 
for more than one positioning method: 

- radio interface timing information 

Signalling between Node B or LMU and CRNC is transferred using lub signalling. 

5.2.1.2.2 Drift RNC 

The DRNC is a UTRAN element that has active link to the UE that shall be located. DRNC may provide the same UP 
frinctionahty as CRNC. 

5.2.2 Node B 

Node B is a network element of UTRAN that may provide measurement results for position estimation and makes 
measurements of radio signals and communicates these measurements to the SRNC. 

The Node B may make its measurements in response to requests (e.g. from the SRNC), or it may autonomously 
measure and report regularly or when there are significant changes in radio conditions (e.g. changes in the RTD). 

5.2.3 Location measurement unit (LMU) 

The Location Measurement Unit (LMU) entity makes measurements (e.g. of radio signals) and communicates these 
measurements to a RNC. The LMU may also perform calculations associated with the measurements. 

All positioning and assistance measurements obtained by an LMU are supplied to a particular CRNC associated with 
the LMU. Instructions concerning the timing, the nature and any periodicity of these measurements are either provided 
by the CRNC or are pre-administered in the CRNC (e.g. using O&M). 

The LMU may make its measurements in response to requests (e.g. from the CRNC), or it may autonomously measure 
and report regularly (e.g. timing of Node B transmissions) or when there are significant changes in radio conditions 
(e.g. changes in the RTD). 

There may be one or more LMU associated with the UTRAN and an UP request may involve measurements by one or 
more LMU. The LMU may be of several types and the CRNCs will select the appropriate LMUs depending on the UP 
method being used. 

The LMU may be used, for example, to measure UTRAN transmissions either UL or DL. These measurements may be 
made either, for example, to locate the UE or to measure a system parameter needed by the UP such as the timing offset 
(RTD) of transmissions of two or more Node Bs. The LMU may also measure other transmissions, such as those of 
satellite navigation systems (i.e. GPS) and either report the measurements for use by the CRNC, or report the 
positioning results as determined by internal calculations of the LMU. The details of the measurements to be made by 
the LMU will be defined by the chosen UP method. 

An LMU makes radio measurements to support one or more positioning methods. These measurements fall into one of 
two categories: 

(a) positioning measurements specific to one UE and used to compute its position; 

(b) assistance measurements applicable to all UEs in a certain geographic area. 
There are two classes of LMU: 

Stand-Alone LMU: communicates with RNCs via the Uu interface; 

- Associated LMU: communicates with RNCs via the lub interface. 

The associated LMU signalling protocol is the NBAP. The protocol for stand-alone LMU signalling has not been 
defined yet. 

NOTE 1 : The stand-alone LMU signalling protocol could be, for example, RRC or LLP, but this is still for further 
study. 
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Stand-Alone LMU 

A stand-alone LMU is accessed exclusively over the UTRAN air interface (Uu interface). There is no other connection 
from the stand-alone LMU to any other UTRAN network element. 

NOTE 2: This does not preclude a stand-alone LMU from also communicating with other access networks (e.g. 
GSM) through interfaces that are not part of the present document. 

A stand-alone LMU has a serving Node B that provides signalling access to its CRNC. A stand-alone LMU also has a 
serving 3G-MSC, VLR and a subscription profile in an HLR. A stand-alone LMU always has a unique IMSI and 
supports all radio resource and mobility management functions of the UTRAN radio interface that are necessary to 
support signalling. A stand-alone LMU shall support those connection management functions necessary to support UP 
signalling transactions with the CRNC and may support certain call control functions of to support signalling to an 
CRNC using a circuit switched data connection. 

NOTE 3: A network operator may assign specific ranges of IMSI for its LMUs and may assign certain digits within 
the IMSI to indicate the associated CRNC. Certain digits in the IMSI may also be used as a local 
identifier for an LMU within an CRNC. 

To ensure that a Stand-alone LMU and its associated CRNC can always access one another, an LMU may be homed 
(camped) on a particular cell site or group of cell sites belonging to one 3G-MSC. For any Stand-alone LMU with a 
subscription profile in an HLR, a special profile may be used to indicate the assigned supplementary services (e.g. the 
SMS-PP MT for data download via the SIM application toolkit, and barring of all incoming and possibly outgoing 
calls). An identifier in the HLR profile also distinguishes an LMU from a normal UE. All other data specific to an LMU 
is administered in the LMU and in its associated CRNC. 

Associated LMU 

An associated LMU is accessed over the lub interface from an RNC. An associated LMU may make use of the radio 
apparatus and antennas of its associated Node B. The LMU may be either a logically separate network element 
addressed using some pseudo-cell ID, or connected to or integrated in a Node B. Signalling to an associated LMU is by 
means of messages routed through the controlling Node B. 

An associated LMU may be separated from the Node B, but still communicate with the CRNC via the Node B lub 
interface. The interface between the associated LMU and its Node B is not part of the present document. 

NOTE 4: An associated LMU is not precluded from also communicating with other access networks (e.g. GSM) 
through interfaces that are not part of the present document. 

Measurements 

The assistance measurements obtained by an LMU are generic and are usable by more than one positioning method. 
These include: 

- Radio Interface Timing measurements: include ATD or RTD of the signals transmitted by Node B, where 
timing differences are measured relative to either some ATD or the signals of another Node B (RTD); 

- Inter-System Timing measurements: include the Absolute Time Difference (ATD) or Relative Time 
Difference between the UTRAN radio signals transmitted by a Node B and an external system such as the GPS 
satellite navigation system or GSM. 

5.2.4 UE 

The UE may transmit the needed signals for uplink based UP measurements and to make measurements of downlink 
signals. The measurements to be made will be determined by the chosen positioning method. 

The UE may also contain LCS applications, or access an LCS application through communication with a network 
accessed by the UE or an application residing in the UE. This application may include the needed measurement and 
calculation functions to determine the UE's position with or without assistance of the UTRAN UP entities. This is 
outside of the scope of this specification. 

The UE may also, for example, contain an independent positioning function (e.g., GPS) and thus be able to report its 
position, independent of the UTRAN transmissions. The UE with an independent positioning function may also make 
use of information broadcast by the UTRAN that assists the function. 
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Signalling protocols and interfaces 



NOTE: This clause describes the information flows, the detailed messages and protocols are described in other 
clauses. 

6.1 LCS signalling between SRNC and MSC/SGSN 

LCS signalling between SRNC and MSC/SGSN is handled through the lu interface, which is described in clause 6.6.1. 

6.2 SRNC signalling to a target UE 

SRNC signalling to a target UE is described in clause 6.6.4.1. 

6.3 Controlling RNC signalling to a standalone LMU 

CRNC signalling to a standalone LMU is described in clause 6.6.4.2. 

6.4 Controlling RNC signalling to an associated LMU 

CRNC signalling to an associated LMU is handled through the lub interface, which is described in clause 6.6.3. 

6.5 RNC-to-RNC signalling for UP support 

The RNC-to-RNC signalling for UP support is handled through the lur interface, which is described in clause 6.6.2. 

6.6 Interfaces 

There are four interfaces through which the UP entities communicate. These are the lu, lur, lub and Uu. 

NOTE: the interfaces between the Internal or External LCS applications and the 3G-MSC or 3G-SGSN are 
outside the scope of the present document. 

6.6.1 lu Interface 

The lu interface is used to communicate between the LCS functional entities in the CN and the UP entities in the 
UTRAN. Further specification of the messages and operations for LCS across the lu interface may be found in 
reference [1]. 

6.6.2 lur Interface 

UP operations at the lur interface are defined in [14]. 

The lur interface is used to communicate between the UP functional entities associated with the SRNC and other RNC 
in the UTRAN. The lur interface is also used to communicate between the SRNC and the Internal UP Applications in 
the UTRAN. The UP entities associated with the SRNC are responsible for co-ordinating and responding to positioning 
requests received from the LCS entities in the CN or Internal Clients. 

When communicating between the SRNC and the UTRAN Internal UP Applications, the messages and protocols are 
the same as those used over the lur interface. 

The lur interface is also used to communicate between the UP Entities in the SRNC and those in other RNC. The 
positioning method, for example, may require measurements by several LMU or Node B, some of which may be 
associated with other RNC. Commands and responses from these UP Entities are communicated over the lur interface. 
In some cases, the UP Entities in the SRNC may make use of entities associated with other RNC. For example, a 
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calculating function may be used in another RNC if the SRNC is too busy or does not contain the function or database 
information required by the chosen positioning method. 

lur shall be used for UP signalling whenever it is available, even in the case when the RNCs connected to different 3G- 
MSCs or 3G-SGSN. 

Within UTRAN, lur supports inter-RNC soft handover. Inter-RNC handover should also include UP, meaning that 
whenever an inter-RNC soft handover occurs, lur should be able to support the functionality of the UP entities in RNCs. 

lur shall be used also to collect RTD and other UP information from Node Bs under different RNCs that are not 
involved in handover. 

6.6.2.1 Signalling between SRNC and DRNC 

Signalling between SRNC and DRNC is used to obtain LCS information specific to a UE that has an UE context to the 
DRNC. 

The signalling between SRNC and DRNC is done by using RNSAP procedures specified in [14] 

6.6.2.2 Signalling between SRNC and CRNC 

Signalling between SRNC and CRNC is used to obtain LCS information and request LCS related transmissions or other 
radio operation (e.g. IPDLs) that is needed by SRNC for a certain location method. The requested information may be 
e.g. GPS assistance data in case a reference GPS receiver is not available at the SRNC or RTD measurement results that 
may be provided by LMUs associated to the CRNC. 

The procedures used for the signalling between SRNC and CRNC are not specified yet. 

6.6.3 lub Interface 

UP operations at the lub interface are defined in [15]. 

The lub interface is used to communicate among the UP entities associated with the CRNC, the Node B and the 
associated LMU. 

This interface passes the request for measurements, the measurement results and requests for UP related transmissions 
or other radio operations needed by the positioning method (e.g. broadcast of parameters needed for a UE-based 
positioning method). Measurement requests and results are signalled by using NBAP procedures. 

6.6.3.1 Signalling between RNC and associated LMU 

Signalling exchanges between an RNC and a LMU under the control of that RNC will be specified in the NBAP 
protocol for associated LMUs. 

The protocol layers employed to enable signalling between the RNC and an associated LMU are defined in [21]. The 
LMU signalling information elements are included directly in the NBAP protocol, defined in [15]. 

6.6.4 Uu Interface 

UP operations at the Uu interface are generally defined in [1]. This specification defines in more detail the procedures 
needed for messaging for each individual positioning method. 

The Uu interface is used to communicate among the UP entities associated with the RNC, the UEs and the stand-alone 
LMU (the Uu interface is also used to communicate between the LCS entities in the CN and the UE. Those 
communications are beyond the scope of this specification). 

This interface may pass measurement requests and results to and from the UE or the stand-alone LMU. 

The Uu interface may also pass UP requests from internal or external LCS Applications at the UE. This is part of the 
NAS procedures and is outside of the scope of this specification. 
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The Uu interface may also be used for broadcast of information that may be used by the UE or stand-alone LMU for 
their UP operations. This may, for example, include timing and code information about nearby Node B transmissions 
that may assist the UE or LMU in making their measurements. 

6.6.4.1 Signalling between SRNC and Target UE 

UP related signalling between an SRNC and a target UE is supported by the RRC protocol as specified in [19]. 

The positioning request to UE signalling flow is generic for all UE-based or UE-assisted positioning methods (OTDOA 
and Network-assisted GPS). 
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RRC Measurement Control 








RRC Measurement Report 
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Figure 6.1 : OTDOA /GPS Positioning IVIessage Flow 

1. The SRNC determines possible assistance data and sends a MEASUREMENT CONTROL request to the UE. 

2. Provided that the UP request meets the privacy criteria, the UE performs the requested measurements. If the UE 
is able to calculate its own position, and this is requested, the UE computes a position estimate based on 
measurements. Any assistance data necessary to perform these operations will either be provided in the 
MEASUREMENT CONTROL request or be available from broadcast sources. The resulting measurements or 
position estimate are returned to UTRAN in a MEASUREMENT REPORT response. If the UE cannot fulfil the 
request, a MEASUREMENT CONTROL FAILURE message is returned. 



6.6.4.1.1 



Assistance Data Delivery to UE 



The assistance data signalling flow illustrated here is generic for the point-to-point delivery of positioning related 
assistance data to the UE, including OTDOA and Network-assisted GPS. 




Figure 6.2: OTDOA or GPS Assistance Data Delivery Flow 

L The SRNC determines assistance data and sends it in the RRC MEASUREMENT CONTROL message to the 
UE. 
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6.6.4.1.2 Error Handling 

The error handling for signalhng on the Uu interface is handled by the RRC protocol in [19]. 



6.6.4.1.3 



Broadcast of Assistance Data 



In the UE-based OTDOA or Network-assisted GPS methods, where the measurements and/or position calculation is 
done in the UE, UTRAN may broadcast assistance data to the UE. 

The assistance data to be broadcast for UE-based OTDOA contains RTD values (e.g. in case of a non-synchronised 
network) and Node B co-ordinates. In addition, the broadcast data may contain other information to simplify the 
OTDOA measurements. The length of the message depends on how many neighbours are included in the assistance 
data. Part of the broadcast message (e.g. the serving and neighbour Node B geographic co-ordinates) may be ciphered. 

The assistance data to be broadcast for assisted GPS may contain a subset of or all of the following information: 
reference time, reference location, DGPS corrections, ephemeris and clock corrections, and almanac and other data. Part 
of the broadcast message may be ciphered. 

The broadcast channel that is used for the OTDOA and GPS assistance data makes use of the common UTRAN 
broadcast service. 

6.6.4.1 .4 Signalling Flow for Assistance Data Broadcast Using the Common UTRAN 

Broadcast Service 

The UTRAN may broadcast location related assistance data to UEs within the system information. 



SYSTEM INFORMATION 



Figure 6.3: Broadcast of system information 



6.6.4.1.5 



UP Assistance Data Ciphering 



To allow control of access to the assistance data, parts of the broadcast assistance data may be ciphered. Ciphering is 
done with a specific ciphering key delivered by the CN for this purpose. The management of the key is described in the 

System Aspects Stage 2 ([!]). 



6.6.4.1.6 



UP Assistance Data Ciphering Algorithm 



The algorithm used for ciphering the UP assistance data is the standard 56-bit Data Encryption Standard (DES) 
algorithm. 

The deciphering of broadcast assistance messages is done in the UEs. The deciphering will utilize the deciphering keys 
delivered during the location update request. Details can be found in 3GPP TS 24.008. 

The RNC ciphers the parts of the UP Broadcast Data message to be protected using the 56-bit DES algorithm and a 
ciphering keys (56 bits) and Ciphering Serial Number (16 bits) for the broadcast location area. 

The ciphered part is variable in length with one bit resolution. By using the UP Broadcast Data message header, the 
UEs can determine what part of message is ciphered. 

Inputs to the 56-bit DES algorithm are the following: 

56-bit key K (deciphering key); 
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16-bit Ciphering Serial Number from broadcast message which is denoted here by IV (Initialisation Vector); 

- plain-text bits (the ciphered part of broadcast message). 

The ciphering process is illustrated in the following diagram. Ciphering is done by producing a mask bit stream which 
is then "XORed" bit-by-bit to the plain-text data to obtain the cipher-text data. First, the Initialisation Vector (IV) is 
concatenated with 0-bits in order to achieve a 64-bit block Ii. This block is then encrypted by the DES algorithm using 
the key K. Output is a 64-bit block I2. This constitutes the first 64 bits of the mask bit stream. If the message is longer 
than 64 bits, then more bits are needed. These are produced by encrypting I2 again by the DES algorithm using the key 
K. The output is a 64-bit block I3. This is the next 64 bits of the mask bit stream. This iteration is continued until enough 
bits are produced. The unnecessary bits from the last 64-bit block Ij are discarded. The figure below illustrates the first 
two mask bit generations and the two ciphered 64-bit blocks. 
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Figure 6.4: Data Assistance Ciphering Algorithm 

Deciphering is done similarly. The same mask bit stream is produced and these are XORed, bit-by-bit, to the cipher-text 
data bits. The result will be the plain-text data. 



6.6.4.2 



Signalling between RNC and stand-alone LIVIU 



Signalling exchanges between an RNC and a stand-alone LMU under the control of that RNC will be specified in the 
RRC protocol for stand-alone LMUs. This does not preclude a stand-alone LMU from also communicating with other 
networks (e.g. GSM) through interfaces (e.g. LLP protocol) that are not part of the present document. 

Each update of the LMU measurement (including the initial one) is triggered by a LCS request from the client that is 
internal to UTRAN. The request may be made directly to the UTRAN LCS entities as the internal clients are considered 
to be "pre-authorised" (section 5) or comes from CN with authentication. 

The following figure illustrate the protocol layers used to support signalling between an RNC and a stand-alone LMU 
over the Uu interface. 

The protocol layers employed to enable signalling between the RNC and a stand-alone LMU are defined in 25.331. The 
LMU signalling information elements are included directly in the RRC protocol, also defined in 25.331. 
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Figure 6.5: Signalling between an RNC and a Stand-Alone LMU using a signalling bearer 



7 General UTRAN UP procedures 

7.1 General procedures in UTRAN for UP 

The General UP procedure in UTRAN starts with a request over lu from the CN. UTRAN then determines the UE 
position by selecting a suitable positioning method. UTRAN then responds to the request with the estimated position 
and possible an associated accuracy. 



7.2 Common procedures supporting UP interaction between 
RNCs 

In the case that the positioning information is needed from an associated LMU in a Node B that is not controlled by the 
SRNC then the transfer of this information needs to be supported on the lur interface. This information is the same 
information that is signalled between an associated LMU and the corresponding CRNC in the case when lur support is 
not needed. 

The SRNC requests the information it requires (e.g. GPS timing of cell measurements) from the CRNC of the Node B 
which has the associated LMU. The CRNC in turn requests the information from the Node B and upon success returns 
the results to the SRNC. 

Similarly when the SRNC needs a Node B measurement on a UE when that Node B is not controlled by that SRNC 
there needs to be support on the lur. One example is the RTT measurement. 

Other information that may need to be signalled over the lur includes LMU parameters (geographical position, covered 
cells etc.). NOTE: Confirmation or FS is needed by R3 experts. 

7.2.1 Signalling in case of SRNS relocation 

In case of SRNC relocation UP functionalities may be transferred in order for DRNC to be able to handle the 
responsibility of SRNC in LCS process. Therefore the Source RNC may transfer the following information to the 
Target RNC : 

last known position, time stamp and accuracy of the position calculation 
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LCS capabilities of the UE 

NOTE: If it is possible to transfer the location service requests that are stored in the Source RNC during SRNS 
relocation is ffs. 

If there is a location procedure going on in order to estimate the position of the UE and a SRNS relocation occurs, the 
location procedure shall be stopped in the old SRNC. After SRNS relocation, the new SRNC then decides if a new 
location procedure should be started. In the UE, the location procedure is going on and LCS information (e.g. 
measurement results) may be sent back to UTRAN if the UE was requested to do so. The new SRNC then decides 
whether it wants to use these information or discard them. 

7.3 Exception procedures 

7.3.1 Procedures in tine SRNC 

When a positioning attempt fails due to failure of a position method itself (e.g. due to inaccurate or insufficient position 
measurements and related data) and the SRNC is unable to instigate another positioning attempt (e.g. due to a 
requirement on response time), the SRNC may return a Location response over the lu interface containing a less 
accurate position estimate. If a less accurate estimate is not available or will not meet the accuracy requirement, the 
SRNC may instead return a Location response message containing no position estimate and indicating the cause of 
failure. 

NOTE: Need to check that lu has enough flexibility 

When a positioning attempt is interrupted by some other unrecoverable error event inside the SRNC, the SRNC shall 
immediately terminate the positioning attempt and return a Location Response message containing the reason for the 
positioning attempt cancellation. In that case, any dialogue previously opened with an LMU for the purpose of 
instigating position measurements for the UE being located may also be aborted by the SMLC. 

7.3.2 Procedures in a LMU 

An LMU shall return an error indication to its CRNC when positioning measurements previously ordered by the RNC 
cannot be provided due to any error condition. 

7.3.3 Procedures in tine target UE 

A target UE shall terminate any positioning procedure or the transfer of RRC positioning assistance data without 
sending any response to the SRNC if any UP RRC message is received from the SRNC that starts some other RRC 
management procedure. The new RRC procedure shall then be executed by the UE. 

7.4 Radio interface timing procedures 

The Radio Interface Timing determination system consists of functions in LMUs and in the SRNC. The system runs 
continuously offering cell timing information for UP. 

7.4.1 LIVIU Functions 

The Radio Interface Timing functionality in the LMU should be capable of performing the following functions: 

The LMU performs necessary radio interface measurements from signals transmitted by Node Bs 

If the LMU contains a common reference clock, e.g. GPS TOW, it time stamps reception of Node B signals. 

If there is no reference clock available, the LMU may make RTD measurements, i.e. measures the time 
difference between arrival of SFNs 

The LMU may perform some processing of measurements, like averaging and filtering, using parameters 
delivered to it, or in their absence using default settings 
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7.4.2 CRNC Functions 

The CRNC must be capable of performing the following functions related to Radio Interface Timing determination: 

The CRNC sends to LMUs requests for Radio Interface Timing measurement information. 

The CRNC will communicate regularly with LMUs; thus, the CRNC can monitor operation of LMUs. If a LMU 
fails to send Radio Interface Timing information, the CRNC shall try to restart the LMU, and if this restarting 
fails, the CRNC shall inform O&M system. CRNC can use also diagnostics messages to query the status of 
LMUs. 

The CRNC receives Radio Interface Timing measurement results from LMUs. 

The CRNC stores or queries extra information required for Node B synchronization determination, like Node B 
and LMU coordinates. Node B identity information. 

The CRNC determines synchronization differences between different downlink signals using LMU 
measurements and other information. 

Synchronization information is delivered for UP piuposes. 

7.4.3 LMU-CRNC Interactions 

The request for Radio Interface Timing measurement information from the CRNC to a LMU contains the following 
parameters: 

- Measurement type. This indicates whether the CRNC wants the LMU to perform ATD (e.g. GPS time stamp of 
signal) or RTD measurements. 

Measurement result reporting frequency. This indicates how often the LMU should send Radio Interface Timing 
measurement results. 

Measurement duration. This indicates how long the LMU should make measurements and report results. 

Instructions about filtering of raw measurement data. 

Instructions about Primary CPICH signals to be measured. The LMU unit can measure autonomously a certain 
number of most strongly received signals. Another possibility is that the CRNC tells which Node B signals it 
should measure. 

In the RTD case, which common Primary CPICH the LMU should use as a reference in the measurements. 

Instruction of how the measurement quality should be reported. 
In case a RTD measurement was requested by the CRNC, the LMU returns the following information to CRNC: 

Identity of the Node B at which the associated LMU is residing 

Primary CPICH info of the measured signals 

SFN-SFN time difference between neighbour cells and reference cell 

Identity of the neighbour cells 

SFN-SFN drift between neighbour cells and reference cell 

time stamp of the measurement (e.g. SFN) 

accuracy of the measurement 
In case a ATD measurement was requested by the CRNC, the LMU returns the following information to the CRNC: 

cell id of the measured cell 

- SFN 
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time stamp (e.g. GPS Time of Week) of the SFN 
Node B clock drift 
accuracy of the measurement 



8 Cell ID based positioning method 

In the Cell ID based method, the SRNC determines the identification of the cell providing coverage for the target UE. 
This subsection outlines the procedures for this positioning method. Sub-section 8.1 provides procedures for the 
determination of the cell ID depending on the operational status of the target UE. Sub-section 8.3 provides a procedure 
for the mapping of the Cell ID to a corresponding SAI to be returned to the LCS application in the CN. The general 
flow to determine the cell ID is shown in figure 8.1. 
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Figure 8.1 : Cell ID Based Method 



8.1 



Cell ID determination 



In order for the SRNC to determine the cell ID when an UP request is received, additional operations may be needed 
depending on the operational status of the UE. 

Figure 8.1 illustrates the procedure for the cell ID based positioning method when the UE is in different RRC states. 
When the LCS request is received from the CN the SRNC checks the state of the target UE. If the UE is in a state where 
the cell ID is available, the target cell ID is chosen as the basis for the UP. In states where the cell ID is not available, 
the UE is paged, so that SRNC can establish the cell with which the target UE is associated. In order to improve the 
accuracy of the LCS response the SRNC may also request RTT or RX Timing Deviation measurements from the Node 
B or LMU associated with the cell ID. The SRNC may also map the cell ID to a corresponding SAI to match the service 
coverage information available in the CN. 

The cell ID based method shall determine the position of the UE regardless of the UE RRC mode (i.e. connected or 
idle). 
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8.1.1 UE Cell ID is not known 

For UE for which the cell ID is not known at the time the UP request is received at the SRNC, the UE may be paged to 
locate its current cell ID. If the UE is in an idle mode and there is a need for it to be paged, then the paging may be 
initiated either by the CN or by the SRNC in UTRAN. For example, the UE can be forced to perform a transition to a 
Cell_FACH state to define the cell ID of its current cell. 

If the UE is in an idle mode, or in a RRC connected state when there is a need to page for the UE to obtain the cell ID, 
the CN may initiate paging, authentication and ciphering, as specified in [22] . 

Alternatively, the cell ID may be determined as the one that was used during the last active connection to the UE. This 
determination should be accompanied by the time-of-day of the last connection in the cell. 

8.1.2 UECell ID is known 

8.1 .2.1 UE not in Soft handover 

The cell ID may be determined as the cell that is providing an active connection for the UE at the time of receiving the 
UP request at the SRNC. 

8.1 .2.2 UE in Soft handover 

In order for the SRNC to provide the geographical co-ordinates of a target UE in soft handover, the SRNC combines the 
information about all cells associated with the UE. 

In soft handover, the UE may have several signal branches connected to different cells, reporting different cell IDs. A 
reference cell ID may be determined by the SRNC based on the coverage area of each cell. The reference cell ID may 
be selected based on one or more of the following principles: 

the cell ID may be selected based on the parameters defining the quality of the received signal branches. That is, 
the cell ID with the best quality signal branch is selected as the reference cell ID; 

the cell ID may be selected that was used during connection set-up between the UE and the serving Node B; 

the cell ID of the cell most recently associated with the UE may be selected;; 

the cell ID of the latest "new" cell that the UE has started to receive, but has not yet been handed over to may be 
selected; 

the cell ID may be selected as the cell to which UE has the shortest distance (to the Node B site); 

the cell ID may be selected as the cell that provides an active connection for the UE at the time of receiving the 
UP request at the SRNC. 

The selection may also be based on RTT measurements, power levels and received signal strengths in UE and related 
Node B or LMU. 

Other relevant mechanisms such as IPDL or SSDT power control should also be taken into account when applying the 
cell ID selection procedure for UE in a soft handover mode. 

8.2 Mapping the Cell ID to Geographic Co-ordinates or a 
Service Area 

A UTRAN cell ID should be mapped to geographical coordinates or a SAI before being sent from UTRAN to the CN. 
The Service Area Identifier may include one or several cells. The mapping may be accomplished either in the SRNC, in 
a Network Management System , including Network Management Unit or by co-operation of various access network 
elements. 

The CN may request the geographical co-ordinates or the SAI, or both for the target UE. The SAI may be used for 
routing of corresponding Emergency calls, or for CAMEL services to correspond to the usage of Cell ID in the core 
network of GSM. However, the MSC shall not send the Service Area Identity to GMLC. 
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Although the mapping of the cell(s) associated with the target UE into geographical co-ordinates by the SRNC is not 
standardised, the response to the CN location request with geographical co-ordinates shall be as defined in [20]. 

In order to determine a cell coverage estimate and to map it to the geographical coordinates or Service Area parameter 
Identity, the SRNC may use parameters such as the best reference signal, RTT in FDD [17] or Rx Timing Deviation 
[18] and knowledge of the UE timing advance in TDD, as well as antenna beam direction parameters. 

Alternatively, the service area coverage of a cell may be determined by using a reference signal power budget. Based on 
the reference signal power budget it is possible to obtain, for example, the Node B transmitted power, isotropic path 
loss, coverage threshold at coverage area border for a given location probability, and a cell radius for an indoor and 
outdoor coverage. 

The SRNC may use a reference signal link budget based cell radius estimate, in conjunction with the cell identifier, to 
make a coverage estimation for the cell(s) related to the target UE. 

Additionally, the SRNC may compare the received power levels with the power budget, whereby more accurate 
information of the position of the UE may be provided. 

Also, the interaction between neighbouring cell coverage areas may be used to determine a more exact UP. 



OTDOA positioning method 



The primary standard OTDOA measurement is the "SFN-SFN observed time difference" observed at the UE (see [17] 
and [18]). These measurements, together with other information concerning the surveyed geographic position of the 
transmitters and the RTD of the actual transmissions of the downlink signals may be used to calculate an estimate of the 
position of the UE. Each OTDOA measurement for a pair of downlink transmissions describes a line of constant 
difference (a hyperbola (see note 1)) along which the UE may be located. The UE's position is determined by the 
intersection of these lines for at least two pairs of Node Bs. The accuracy of the position estimates made with this 
technique depends on the precision of the timing measurements, the relative position of the Node Bs involved (see note 
2), and is also subject to the effects of multipath radio propagation. This is illustrated in the figure 9.1. 

NOTE 1 : This is really a figure in three dimensions, a hyperboloid. For convenience here, this will be simplified to 
the hyperbola representing the intersection of this surface with the surface of the earth. For location 
service in three dimensions the hyperboloid must be considered. 

NOTE 2: The geometry of the Node B positions may affect the accuracy of the position estimate. The best results 
are when the Node Bs equally surround the UE. If they do not, there is a reduction in accuracy, which is 
sometimes termed the Geometric Dilution of Position (GDP). 

The primary OTDOA measurements (made by the UE) are sent to the SRNC. These measures are sent via signalling 
over the Uu, lub (and lur) interfaces between the UE and the SRNC. The calculation function makes use of the 
measurements, the known positions of the transmitter sites and the RTD of the transmissions to estimate the UE's 
position. 
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Figure 9.1 : OTDOA Positioning IVIethod 

The OTDOA method may be operated in two modes: UE-assisted OTDOA and UE-based OTDOA. The two modes 
differ in where the actual position calculation is carried out. 

In the UE-assisted mode, the UE measures the difference in time of arrival of several cells and signals the measurement 
results to the network, where the SRNC carries out the position calculation. 

In the UE-based mode, the UE makes the measurements and also carries out the position calculation, and thus requires 
additional information (such as the position of the measured Node Bs) that is required for the position calculation. 

The signalling requirements for the two OTDOA modes are described in subclause 9.6. As the UP involves 
measurements, there is always uncertainty in the results. Physical conditions, errors and resolution limits in the 
apparatus all contribute to uncertainty. To minimise the uncertainty in the UP result, it is important that as many 
measurements of OTDOA (and assistance data as RTT in FDD and Rx Timing Deviation in TDD) as are possible for a 
UE are provided to the UE. Thus it is important that the standard UP method not be restricted to rely on a single 
measure. The UE thus provides SFN-SFN observed time difference measurements for as many cells as it can receive. 
The cells to be measured shall include those in the active set and the monitored set. 

In order to support the OTDOA method, the positions of the UTRAN transmitters needs to be accurately known by the 
calculation function in SRNC (for UE-assisted method) or UE (for UE-based method). This information may be 
measured by appropriate conventional surveying techniques (see note 3). The surveyed position should be the electrical 
centre of the transmitting antenna (and not the position of the radio equipment building). The use of antenna diversity, 
beamforming or beam steering techniques may cause the effective antenna position to change with time and this 
information is also needed to perform calculations. The methods of measuring the position of the UTRAN transmitters 
are outside the scope of the present document. 

NOTE 3: These surveying methods may, for example, make use of a GPS receiver. 

In order to support the OTDOA method, the RTD of the DL transmissions must also be known to perform the 
calculation. If the UTRAN transmitters are unsynchronised, the RTD will change over time as the individual clocks 
drift. Thus, measurements of RTD may need to be made regularly and the calculation function updated appropriately. 
The measurement of the RTD is outside the scope of the present document (see note 4). 

NOTE 4: One convenient method is to make use of an LMU at a fixed position. This unit measures the observed 
time differences of all the local transmitters. These measures may then be converted (translated) into the 
actual (absolute) relative time difference for each of the transmitters by making use of the known position 
of the LMU and the transmitters. 

In some conditions a sufficient number of cells may not be available for measure at the UE. This may occur, for 
example, if the UE is located quite close to the UTRAN transmitter and its receiver is blocked by the strong local 
transmissions. This is referred to as the "hearability" problem. 
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9.1 Use of Idle Periods (FDD only) 



Location based services needs the support of physical layer as a prerequisite, so that the measurements required for the 
UE position calculation can be carried out. In UTRAN there are several factors that must be taken into account while 
considering the physical layer procedures related to location services: 

hearability: a basic consequence of a CDMA radio system is that a terminal near its serving Node B cannot hear 
other Node Bs on the same frequency. In order to calculate its position the UE should be able to receive at least 
three Node Bs. To facilitate this some special means are required; 

asynchronous network causes significant uncertainty to the time-difference-of-arrival (TDOA) measurements. 
To compensate for the effects of this, the relative time difference (the synchronicity) between Node B 
transmissions must be measured, and used for correcting OTDOA measurement; 

capacity loss: signalling related to position calculation may take capacity from other services. This capacity loss 
should be minimised. 

Based on the results in [23] a solution for the above mentioned hearability problem is the IPDL method. In this method 
each Node B ceases its transmission for short periods of time (idle periods). During an idle period of a Node B, 
terminals within the cell can measure other Node Bs and the hearability problem is reduced. Also, during idle periods 
the real time difference measurements can be carried out. Because the IPDL method is based on downlink the location 
service can be provided efficiently to a large number of terminals simultaneously. 

The specification and operation of the IPDL technique are provided in the following subclause. 

9.1 .1 Operation and specification of idle periods 

The operation and specification of idle periods can be found in [16]. 

9.2 Relative Time Difference (RTD) 

In order to calculate the estimate of the position of the UE, the calculation function needs to know: 

the OTDOA measurements; 

the surveyed geographic positions of the Node Bs that have had their signals measured; and 

the actual relative time difference between the transmissions of the Node Bs at the time the OTDOA 
measurements were made. 

The accuracy of each of these measurements contributes to the overall accuracy of the position estimate. The 
measurement of the RTD is described in the following. 

There are several approaches to determining the RTD. One is to synchronise the transmissions of Node B. In this 
technique the RTD are known constant values (see NOTE) that may be entered in the database and used by the 
calculation function when making a position estimate. The synchronisation must be done to a level of accuracy of the 
order of tens of nanoseconds (as 10 nanoseconds uncertainty contributes 3 metres error in the position estimate). Drift 
and jitter in the synchronisation timing must also be well controlled as these also contribute uncertainty in the position 
estimate. Synchronisation to this level of accuracy is currently only readily available through satellite based time- 
transfer techniques. Generally in the TDD operating mode, the Node Bs are synchronised. 

NOTE: The transmission times may all be aligned to a common reference (such as UTC) in which case all RTD 
have a common value. However, in a more general case the transmissions may have a fixed offset with 
reference to UTC, and thus the RTD values are non-zero and may be stored in the database for use by the 
calculation function. 

Alternatively (typically in FDD mode). Node Bs may be left to free run within some constraint of maximum frequency 
error. In this scenario, the RTD will change (slowly) with time. The rate of change will depend on the frequency 
difference and jitter between Node Bs. If, for example, the maximum frequency difference between two Node Bs is 
+10'^, then the start of transmission of a 10 millisecond code sequence will drift through a cycle in about 1 390 hours 
(or 57 days). With this relatively slow rate of drift the RTD can be measured by fixed LMUs at known positions and 
stored in the database for use by the calculation function. The jitter and drift of the individual oscillators in each Node B 
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may cause the change of timing to slow, remain constant or reverse direction over time. Ongoing measurements of the 
RTD may be made to assure the most current values are available for the calculation function. The RTD measurement 
units may be co-located with the Node Bs or installed at other convenient positions in the UTRAN coverage area, and 
report their results through the UTRAN signalling. 

The LMUs may directly measure the RTD between neighbouring and reference cells and return the measurements to the 
CRNC. Alternatively the LMUs may measure the ATD of the neighbouring and reference cells and return the 
measurements to the CRNC. If the CRNC is not the SRNC the information is also forwarded from CRNC to SRNC. 
The SRNC then uses the ATD measurements to calculate the RTD values. The information to be transferred in each 
case are listed in 7.6.3. 



9.3 Time of Day (ToD) 



If there are frequency drifts between the (unsynchronised) Node Bs, as noted in subclause 9.2, the OTDOA 
measurements must be reported together with the time-of-day they were made (timestamp). This is necessary so that the 
appropriate value of the RTD may be used by the calculation function. 

In order to assure less than a 20 nanosecond uncertainty in the RTD value, the time of day must be known to better than 
10 seconds (if the maximum frequency difference between the Node Bs is +10'^). The method by which the ToD is 
measured is the system the frame number, which provides a 10 millisecond resolution and can be unambiguous up to 
40.95 seconds. 



9.4 Node B Synchronisation 



It is preferable that the positioning methods do not require the Node B to be synchronised. The needed level of 
synchronisation accuracy for UP is not by any means straightforward to achieve. The necessary information of RTD 
between Node Bs can be measured by LMU and distributed in the network (e.g. as broadcast information). Also, the 
measurements of RTD may benefit from the IPDL option. 

In the TDD operating mode the Node Bs will typically be synchronised and this may be of assistance to the UP 
technique. 

9.5 OTDOA-IPDL and OTDOA IVIodes 

There are two modes of operation for the OTDOA-IPDL and OTDOA methods. 

In the UE-assisted mode, the UE measures the difference in time of arrival of several cells and signals the measurement 
results to the network, where the SRNC carries out the position calculation. 

In the UE-based mode, the UE makes the measurements and also carries out the location calculation, and thus requires 
additional information (such as the position of the measured Node Bs) that is required for the position calculation. This 
information is provided by the System Information Broadcast. 

9.5.1 Information to be transferred between UTRAN elements 

Table 9. 1 lists the required information for both UE-assisted and UE-based modes that may be sent from SRNC to UE. 
The required information can be signalled to the UE either in a broadcast channel or partly also as dedicated signalling. 
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Table 9.1 : Information to be transferred from SRNC to UE ('Yes' = information required, 'No' ; 

Information not required) 



Information 


UE- 
assisted 


UE-based 


Intra frequency Cell Info (neighbour list) 


Yes 


Yes 


Ciphering information for UP (see note) 


No 


Yes 


IVIeasurement control information (idle period locations) 


Yes 


Yes 


Sectorisation of the neighbouring cells 


No 


Yes 


IVIeasured RID values for Cells mentioned at Intra 
frequency Cell Info 


No 


Yes 


RTD accuracy 


No 


Yes 


Measured roundtrip delay for primary serving cell 


No 


Yes 


Geographical position of the primary serving cell 


No 


Yes 


Relative neighbour cell geographical position 


No 


Yes 


Accuracy range of the geographic position values 


No 


Yes 


NOTE: The idea behind UP specific ciphering information is e.g. that the operator 
can sell information that the UE needs for calculating its position. For 
reference in the GSIVI world see [3]. 



The information that may be signalled from UE to SRNC is listed in table 9.2. 

Table 9.2: Information to be transferred from UE to SRNC 



Information 


UE- 
asslsted 


UE-based 


OTDOA measurement results 


Yes 


No 


OTDOA measurement accuracy 


Yes 


No 


UE geographical position 


No 


Yes 


Position accuracy indicator (based on the signalled and 
measurement accuracies) 


No 


Yes 



Table 9.3 shows the information that may be transferred from Node B to its CRNC. If the CRNC is not the SRNC the 
information is also forwarded from CRNC to SRNC. 

Table 9.3: Information to be transferred from Node B/LMU to CRNC and between RNCs 



Information 


UE assisted 


UE based 


Measured RTD or ATD values for Cells mentioned at 
Intra frequency Cell Info 


Yes 


Yes 


RTD or ATD accuracy 


Yes 


Yes 



Table 9.4 shows the information that may be transferred between RNCs. 

Table 9.4: Information to be transferred between RNCs 



Information 


UE assisted 


UE based 


Geographical location of the primary serving cell 


Yes 


Yes 


Relative neighbour cell geographical location 


Yes 


Yes 


Accuracy range of the geographic location values 


Yes 


Yes 



9.6 OTDOA network positioning procedures 

The following diagram illustrates the operations for the OTDOA method for UP when the request for positioning 
information is initiated by an LCS application from the CN. 

This illustration only includes the information flow related to UP operations and does not indicate other operations that 
may be required, for example, to establish a signalling connection between the UE and the SRNC. Also not illustrated is 
the signalling used to initiate the location service request from the CN or a UE-based application. 



£75/ 



3GPP TS 25.305 version 3.4.0 Release 1999 



31 



ETSI TS 125 305 V3.4.0 (2000-12) 



UE 



Node B 



SRNC 



OTDOA measurements request 



I 



UE Rx-Tx timing request 
^ 



] 
OTDOA measurements 



1 

I 
UE Rx-Tx timing measurements 



T 



CN 



Location request 



RTT measurements request 



RTT measurements 



Location estimate 



Figure 9.2: OTDOA Signalling Operations 

1 . The operation begins with an authenticated request for positioning information about a UE from an application 
in the CN being received at the SRNC. The SRNC considers the request and the UTRAN and UE capabilities. 

2. The SRNC requests from the UE the measurement of the OTDOA for the signals in the active and 
neighbourhood sets. These measurements may be made while the UE is in the idle state or while it is connected. 

3. If it is considered advantageous to do so, the SRNC requests the UE Rx-Tx timing difference information from 
the UE. 

4. The UE returns the OTDOA measures to the SRNC. The SRNC receives the OTDOA information and co- 
ordinates obtaining other information to support the calculation request. 

5. The UE returns the UE Rx-Tx timing difference information to the SRNC, together with a time stamp of when 
the value was obtained. 

6. If there are insufficient OTDOA measures, or it is otherwise considered advantageous to do so, the SRNC 
requests the RTT measure for the UE from the serving Node B. 

7. The SRNC requests the RTD measures for the associated transmitters from the associated database. These may 
be stored locally if they are constant over time, otherwise they must be updated to represent the RTD timing at 
the time-of-day the OTDOA measurements were made. 

8. The Node B returns the RTT measures to the SRNC if they were requested. 

9. The SRNC using the OTDOA, RTD and, if necessary, RTT information performs a position calculation. The 
calculation may include a co-ordinate transformation to the geographic system requested by the application. The 
position estimate includes the position, the estimated accuracy of the results and the time of day of the estimate. 

10. The SRNC passes the position estimate to the CN. 
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10 Network-assisted GPS positioning method 

When GPS is designed to inter-work with the UTRAN, the network assists the UE GPS receiver to improve the 
performance in several respects. These performance improvements will: 

- reduce the UE GPS start-up and acquisition times; the search window can be limited and the measurements sped 
up significantly; 

increase the UE GPS sensitivity; positioning assistance messages are obtained via UTRAN so the UE GPS can 
operate also in low SNR situations when it is unable to demodulate UE GPS signals; 

allow the UE to consume less handset power than with stand-alone GPS ; this is due to rapid start-up times as the 
GPS can be in idle mode when it is not needed. 

The Network-assisted GPS methods rely on signalling between UE GPS receivers (possibly with reduced complexity) 
and a continuously operating GPS reference receiver network which has clear sky visibility of the same GPS 
constellation as the assisted UEs. GPS reference receivers may be connected to the UTRAN to enable derivation of UE 
assistance signals. 



SRNC 



UP Request or 



request to issue assistance 
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Figure 10.1: Network-assisted GPS methods 



10.1 Timing calibration 



Timing calibration is achieved by using UE or UTRAN GPS timing measurements as specified in [17]. 



10.2 Tinning assistance 



The UTRAN may derive the estimated UE position using UTRAN parameters (e.g. Cell-ID or IPDL) and may use this 
information, in conjunction with satellite specific ephemeris data received from the GPS reference receiver network, to 
derive the estimated times of arrival (code phases) for equivalent GPS satellite signals received by the UE -based GPS 
receiver functionality. The estimated code phase data may be conveyed, together with Tutran-gps (as specified in [17] 
and [18]), from the UTRAN to the UE using higher layer signalling. The estimated code phase data value is uncertain to 
a degree depending on the accuracy of the UTRAN timing calibration and initial position determination methods used. 
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10.3 Data assistance 

The UE may receive GPS information through the UTRAN radio interface, using higher layer signalHng. 

When the UE is unable to detect a sufficient number of satellites, the assisted GPS method can be combined with other 
positioning methods. Altitude assistance can compensate for one satellite measurement. 

The assistance data signalled to the UE may include all information listed below or a selected subset: 

data assisting the measurements; e.g. reference time, visible satellite list, satellite signal Doppler, code phase, 
Doppler and code phase search windows. This data can be valid for a few minutes (e.g., less than 5 minutes) or 
longer depending on the code phase and Doppler search window size that can be accommodated by the UE; 

data providing means for position calculation; e.g. reference time, reference position, satellite ephemeris, clock 
corrections. Satellite ephemeris and clock corrections data can be used for up to six hours. 

NOTE: Certain types of GPS Assistance data may be derived, wholly or partially, from other types of GPS 
Assistance data. 

If DGPS is utilised, then differential corrections may also be transmitted. If Selective Availability is turned off, these 
corrections can be valid for a few minutes or more. The DGPS data is valid for a large geographical area, so one 
centrally located reference receiver can be used to service this large region. 

10.4 UE search 

Provided that timing assistance, data assistance, and/or frequency reference (see Annex A) is available in the UE, they 
should be applied in the GPS signal search procedure. The UE search procedure involves a three-dimensional search for 
a satellite pseudorandom code, time of arrival of a signal and the associated carrier Doppler. 

"Modulation wipe-off" is defined here to mean a removal of the GPS navigation data bit modulation to GPS signals 
received at the UE, through the application of UTRAN timing and data assistance provided from the UTRAN to the UE. 
This process allows the UE to coherently integrate received GPS signals beyond 1 data bit period (i.e., 20 milliseconds). 



10.5 Position determination 

There are two types of network-assisted GPS methods, namely UE-based and UE-assisted, which differ according to 
where the actual position calculation is carried out. 

Computation of the position fix can either be performed in UTRAN (i.e. SRNC) for UE-assisted or in the UE for 

UE-based. 

The UE-based method maintains a full GPS receiver functionality in the UE, and the location calculation is carried out 
by the UE, thus allowing stand-alone location fixes. 

In the UE-assisted method, the UE employs a reduced complexity GPS receiver functionality. This carries out the 
pseudorange (code phase) measurements. These are signalled, using higher layer signalling, to the specific network 
element that estimates the location of the UE and carries out the remaining GPS operations. In this method, accurately 
timed code phase signalling (as specified in [17] and [18]) is required on the downlink. If DGPS is performed in the UE, 
then differential corrections must be signalled to it. On the other hand, DGPS corrections can be applied to the final 
result in the network to improve the location accuracy without extra signalling to the UE. 

1 0.5.1 Information to be transferred between UTRAN elements 

Table 10.1 lists information for both UE-assisted and UE-based modes that may be sent from SRNC to UE. This 
information can be signalled to the UE either in a broadcast channel or as dedicated signalling. 
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Table 10.1 : Information that may be transferred from SRNC to UE('Yes' = information applicable 'No' 

information not applicable 



Information 


UE-assisted 


UE-based 


Number of satellites for which assistance is provided 


Yes 


Yes 


reference time for GPS (Tutran-gps) (specified in [17] 
and [18]) 


Yes 


Yes 


3-d reference location (specified in [1 7]) 


No 


Yes 


ionospheric corrections 


No 


Yes 




Yes 


Yes 


Ephemeris & clock corrections 


Yes 


Yes 


UTC offset 


No 


Yes 


DGPS corrections 


No 


Yes 


almanac data 


Yes 


Yes 


real-time integrity (e.g. a list of unusable satellites) 


No 


Yes 


doppler (0'" order term) 


Yes 


No 


Doppler Search Window width 


Yes 


No 


doppler (1^' order term) 


Yes 


No 


azimuth 


Yes 


No 


elevation 


Yes 


No 


code phase 


Yes 


No 


code phase centre and search window width 


Yes 


No 



The information that may be signalled from UE to SRNC is listed in table 10.2. 

Table 10.2: Information that may be transferred from UE to SRNC 



Information 


UE-assisted 


UE-based 


reference time for GPS (Tue-gps) (specified in [17] and 
[18]) 


Yes 


Yes 


serving cell information 


No 


Yes 


Latitude/Longitude/Altitude/Error ellipse 


No 


Yes 


velocity estimate in the UE 


No 


Yes 


satellite ID for which measurement data is valid 


Yes 


No 


Whole/Fractional chips for information about the code- 
phase measurement 


Yes 


No 


G/No of the received signal from the particular satellite 
used in the measurements 


Yes 


No 


doppler frequency measured by the UE for the 
particular satellite 


Yes 


No 


pseudorange RMS error 


Yes 


No 


multipath indicator 


Yes 


No 


number of Pseudoranges 


Yes 


No 



Table 10.3 shows the information that may be transferred from Node B to its CRNC. If the CRNC is not the SRNC the 
information is also forwarded from CRNC to SRNC. 

Table 10.3: Information that may be transferred from Node B/LMU to CRNC and between RNCs 



Information 


UE-assisted 


UE-based 


reference time for GPS (Tutran-gps) (specified in [17] 
and [18]) 


Yes 


Yes 



Additional parameters, such as round trip time (RTT) in FDD or Rx Timing Deviation in TDD, UE receiving 
transmitting time (UE Rx-Tx), SFN-SFN observed time difference and CPICH Ec/No, may be used to improve the 
performance of UE-assisted GPS. All the additional parameters are defined in [17] and [18] and can be made available 
through RRC signalling. Furthermore, to those UE technologies requiring externally provided sensitivity and time 
aiding data, some navigation bits may be sent from UTRAN to UE for sensitivity assistance and time recovery. 
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1 0.6 Network Assisted GPS positioning Procedure 

The diagram in Figure 10.1 illustrates the operations for the network assisted GPS when the request for position 
information is initiated by a LCS application signalled from the Core Network. A detailed description of the positioning 
procedure is given as follows. Note that the procedure is for illustration purpose and actual implementations may vary. 

1 . The operation begins with an authenticated request for positioning information about a UE from an application 
in the core network being received at the SRNC. The SRNC acts as interface between the Core Network and the 
UP entities in the UTRAN. 

2. The SRNC considers the request and the capabilities of the UE and the network. 

3. Depending on UE's request, the SRNC sends to the UE certain assistance information, which may include part of 
the following information: the reference time for GPS, the satellite IDs, the Doppler frequency, the search 
window and its centre, the ephemeris and clock corrections, the almanac, and other information specified in 

10.5.1 and 10.5.2. 

For UE-based method (10.5.1), jump to step 7. 

For UE-assisted method (10.5.2), the SRNC may optionally requests the following information before 
sending the assistance message(s) to the UE: the LMU update*, the RTT measurements (from the Node Bs in 
the active set) to compensate for the one-way propagation delays. The LMU (associated or stand-alone) 
returns the information containing the time difference between the Node B and the GPS to the CRNC. The 
Node B returns its RTT measurement to the CRNC. If the CRNC is not the SRNC, the CRNC forwards these 
information to SRNC. 

4. The SRNC requests from the UE the measurement of GPS satellite pseudoranges and other information specified 
in 10.5.2. These measurements may be made while the UE is either idle or connected. The SRNC may request 
SFN-SFN Observed Time Difference measurements and Rx-Tx timing difference information from the UE to 
support the processing related to the RTT measurements. 

5. The UE returns to the SRNC the measurement of GPS satellite pseudoranges and other information specified in 

10.5.2 . If requested, the UE may also return the SFN-SFN measurements and the Rx-Tx time difference 
information, together with a time stamp of when these values were obtained. 

6 The UE position is calculated in the SRNC. 

7. If there is insufficient information to yield a UE positioning estimate, the SRNC may start a new process from 
step 3. 

8. In case of UE based method, UE returns the position estimate to the SRNC. This estimate includes the position, 
the estimated accuracy of the results and the time of the estimate. 

9. The SRNC passes the position estimate to the CN. 

NOTE: The LMU update (of the time difference between the GPS and the Node B) may be performed on a per- 
request basis (with respect to each UP request) or be performed timely that is independent of individual 
UP request. The latter is preferable when there are large volume of UP requests. 



10.7 Real time integrity 



An Integrity Monitor (IM) function should detect unhealthy (i.e., failed/failing) satellites. Excessively large pseudo 
range errors, as evidenced by the magnitude of the corresponding DGPS correction determined by the IM, may be used 
to detect unhealthy satellites. Unhealthy satellites should be detected very close to the occurrence of the satellite failure 
(e.g. 10 seconds) and marked in an unhealthy satellite list as unusable/bad. When unhealthy satellites are detected, the 
assistance and/or DGPS correction data should not be supplied for these satellites. Upon receiving the list of unhealthy 
satellites from the SRNC, the UE should discard data associated with these satellites in its positioning calculation. 

The IM function should also inform the UE of measurement quality in DGPS modes when satellites are healthy. When 
the error in the IM computed position is excessive for solutions based upon healthy satellites only, DGPS users should 
be informed of measurement quality through the supplied User Differential Range Error (UDRE) adjusted values based 
on the operation of the IM. Note that UDRE is one of the lEs contained in the DGPS information ([19]). 
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1 1 Information storage 



NOTE This clause just outlines the information that may need to be stored in the UTRAN UP that may need to 
be standardised (if any). 
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Annex A (informative): 
Definitions and Terms 



This annex provides definitions and terms for the general LCS. Not all of these are applicable to the UTRAN 
environment. 

CAMEL: CAMEL is a network functionality, which provides the mechanisms of Intelligent Network to a UE. 

Current Location: after a location attempt has successfully delivered a location estimate and its associated time stamp, 
the location estimate and time stamp is referred to as the 'current location' at that point in time. 

Deferred location request: a location request where the location response (responses) is (are) not required 
immediately. 

Frequency reference: the frequency reference of the UE obtained from the UTRAN radio interface that may be used to 
minimize the frequency search associated with acquiring GPS satellite signals. When the UE acquisition process is 
aligned to this reference, the carrier Doppler uncertainty that must be searched for a particular satellite signal need only 
account for minor residual uncertainties related to UE dynamics and initial position. This frequency reference may also 
be used to maintain the UE's estimate of GPS time between positioning events, thus making accurate GPS time 
available within the UE to support reacquisition of satellite signals. 

Global Positioning System: the Global Positioning System (GPS) consists of three functional elements: Space 
Segment (satellites). User Segment (receivers), and Control Segment (maintenance etc.). The GPS receiver estimates its 
own location based on the observed times of arrival of the satellite signals. 

Immediate location request: a location request where a single location response only is required immediately. 

Initial Location: in the context of an originating emergency call the location estimate and the associated time stamp at 
the commencement of the call set-up is referred to as 'initial location'. 

Last Known Location: the current location estimate and its associated time stamp for Target UE stored in the LCS 
Server is referred to as the 'last known location' and until replaced by a later location estimate and a new time stamp is 
referred to as the 'last known location'. 

LCS (Location Services): LCS is a service concept in system (e.g. GSM or UMTS) standardisation. LCS specifies all 
the necessary network elements and entities, their functionalities, interfaces, as well as communication messages, due to 
implement the location service functionality in a cellular network. 

NOTE: LCS does not specify any location based (value added) services except locating of emergency calls. 

LCS Client: a software and/or hardware entity that interacts with a LCS Server for the purpose of obtaining location 
information for one or more UEs. LCS Clients subscribe to LCS in order to obtain location information. LCS Clients 
may or may not interact with human users. The LCS Client is responsible for formatting and presenting data and 
managing the user interface (dialogue). The LCS Client may reside in the UE. 

LCS Client Access barring list: an optional list of MSISDNs per LCS Client where the LCS Client is not allowed to 
locate any MSISDN therein. 

LCS Client Subscription Profile: a collection of subscription attributes of LCS related parameters that have been 
agreed for a contractual period of time between the LCS client and the service provider. 

LCS Feature: the capability of a PLMN to support LCS Client/server interactions for locating Target UEs. 

LCS Server: a software and/or hardware entity offering LCS capabilities. The LCS Server accepts requests, services 
requests, and sends back responses to the received requests. The LCS server consists of LCS components, which are 
distributed to one or more PLMN and/or service provider. 

Local Service: a service, which can be exclusively provided in the current serving network by a Value added Service 
Provider. 

Local Information: information related to a given location, or general information, which is made available in a given 
location. 
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Location (/location detecting): location is a functionality, which estimates a geographical location (of e.g. a UE). 

Location (Based) Application: a location application is an application software processing location information or 
utilising it in some way. The location information can be input by a user or detected by UTRAN or UE. Navigation is 
one location application example. 

Location Based Service (LBS): a service provided either by teleoperator or a 3"* party service provider that utilises the 
available location information of the terminal. Location Application offers the User Interface for the service. LBS is 
either a pull or a push type of service (see Location Dependent Services and Location Independent Services). 

Location Dependent Service: a service provided either by teleoperator or a 3"* party service provider that is available 
(pull type) or is activated (push type) when the user arrives to a certain area. It doesn't require any subscription in 
advance, but the push type activation shall be confirmed by the user. The offered service itself can be any kind of 
service (e.g. a public Xerox machine or the discount list in a store). 

Location Estimate: the geographic location of a UE expressed in latitude and longitude data, and optionally altitude 
data. The Location Estimate shall be represented in a well-defined universal format. Translation from this universal 
format to another geographic location system may be supported, although the details are considered outside the scope of 
the primitive services. 

Location Independent Service: a service provided either by teleoperator or a 3^"^ party service provider that is available 
and therefore can be activated anywhere in the network coverage. It is activated by the user's request or by other user's 
activated service, and therefore it requires a subscription in advance (pull type). The offered service itself can be any 
kind of service (e.g. MMS, SWDL, or LBS !). 

Location method (/locating method): a principle and/or algorithm which the estimation of geographical location is 
based on, e.g. AOA, TO A, TDOA. For example, GPS is based on TO A, and E-OTD (on GSM) is based on TDOA. 

Location technology (/locating technology): a technology or system concept including the specifications of RF 
interfaces, data types, etc. to process the estimation of a geographical location, e.g. GPS, E-OTD (GSM), and IPDL- 
TDOA (WCDMA). 

PLMN Access barring list: an optional list of MSISDN per PLMN where any LCS Client is not allowed to locate any 
MSISDN therein except for certain exceptional cases. 

Predefined area: a geographical area which is not related to cell or radio coverage. The UE may take special action 
when it recognises it has entered or left a predefined area. 

Privacy Class: list of LCS Clients defined within a privacy exception class to which permission may be granted to 
locate the target UE. The permission shall be granted either on activation by the target UE or permanently for a 
contractual period of time agreed between the target UE and the service provider. 

Privacy Exception List: a list consisting of various types of privacy classes (i.e. operator related, personal etc.). 
Certain types of classes may require agreement between the service provider and the target UE. 

Prohibited area: an area where the UE must not activate its transmitter. The Prohibited area may be a Predefined area 
described above or related to radio cell(s). 

Subscription Profile: the profile detailing the subscription to various types of privacy classes. 

Target UE: the UE being located. 
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Annex B (informative): 

Reference IVIodel of Functional Entities for UTRAN UP 

The UTRAN functional entities for UP are shown in figure B.l. In this reference model, the LCS clients in the core 
network communicate with the UTRAN UP entities across the lu interface. The RNC LCS Handling Entities and the 
Positioning Handing Entities work together with the UE to measure and calculate the position information for the 
requested target UE. These entities within the UTRAN are described in more detail in the following subclauses. 

The figure shows the general arrangement of the UP function in UTRAN. Communication among these entities makes 
use of the messaging and signalling capabilities of the UTRAN across the lu, lur, lub and Uu interfaces. A LMU is also 
added to the UTRAN to make measurements as needed by the selected positioning method. 

This figure does not include elements of 3G Core Network, but focuses on those that participate with the UP functions 
in the UTRAN. The association of the LCS entities within the Core Network (CN) (e.g. with 3G-MSC or 3G-SGSN) is 
outside the scope of the present document and is not illustrated in the diagram. 

Within the UTRAN, the UP Entities may be associated with, or part of the RNC, the Node B and the UE. Internal LCS 
Applications may also be part of the RNC and the UE. 

The UE Position Calculation Function (PCF) is logically associated with the SRNC in UTRAN. 

The UP in UTRAN also makes use of the standardised lur interface between RNCs, when Node B information, 
measurements and results are collected. 

The functional model presented in the figure includes functional entities for UE utilising either or both circuit switched 
(CS) and packet switched (PS) services. This model also supports of all the entities needed for different positioning 
methods (e.g. network-based, UE-based, UE-assisted, and network assisted (see note 1) methods) exploiting either 
uplink or downlink measurements. 

NOTE 1 : In this approach UE may use the GPS technique but still make use of auxiliary information from the 
serving network. 

Implementations may often associate the UTRAN LCS Entities with an RNC (as illustrated in the figure). However, for 
networks with a small volume of LCS requests, the LCS Entities in the UTRAN may also be implemented as a separate 
element (server) which interfaces with the RNCs, and the Node B / LMUs. 
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Figure B.l : UTRAN UP Functional Entities 
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Several functional groupings may be defined to describe the UP functions. These groupings occur in both the CN and 
the UTRAN. The overall LCS functional grouping is described in reference [1]. Each grouping encompasses a number 
of functional components and functions. 

Within UTRAN the functional entities may be grouped as follows: 

the Internal Client group that includes: 

- Internal UTRAN Location Client Function (U-LCF); 
the UTRAN System Handling group that includes: 

- UTRAN Location System Control Function (U-LSCF), 
UTRAN Location System Operations Function (U-LSOF); 

the UTRAN Positioning group that includes: 

- UTRAN Position Radio Co-ordination Function (U-PRCF), 

- UTRAN Position Calculation Function (U-PCF), 

- UTRAN Position Signal Measurement Function (U-PSMF), 

- UTRAN Position Radio Resource Management (U-PRRM). 

The functions within the UTRAN are described in more detail in the following subclauses. 

B.1 Internal Client Group 

B.1 .1 internal UTRAN Location Client Function (U-LCF) 

The UTRAN Location Client Function (U-LCF) represents a logical interface between the internal UTRAN LCS 
applications and the LCS RNC Handling entities (e.g. the Location System Control Function (U-LSCF) in the RNC). 

NOTE: There is not necessarily a requirement for a LCCF (Location Client Control Function) for the UTRAN 
Internal Client as is described for external clients in reference [1] (the system stage specification). 

The UTRAN may make use of positioning information for internal operations such as location assisted handover. In 
such a case, a U-LCF representing the internal UTRAN LCS application may communicate with the U-LSCF to request 
and receive the positioning information. 

B.2 UTRAN System Handling group 

B.2.1 UTRAN Location System Control Function (U-LSCF) 

The UTRAN Location System Control Function (U-LSCF) in RNC is responsible for co-ordinating UP requests within 
the RNC handling entity. This function manages call-related and non-call-related UP requests and allocates network 
resources for handling them. This function "insulates" the Location clients in the Core Network from the detailed 
operation of the positioning method in order that the UTRAN may be used by several types of core network and with 
several positioning methods. 

The U-LSCF provides flow control between simultaneous UP requests. Simultaneous UP requests must be queued in a 
controlled manner to account for priority requests (e.g. for Emergency Clients). The details of the flow control, priority 
selection and queuing are beyond the scope of the present document. 

The U-LSCF will select the appropriate positioning method based on the availability of resources and parameters of the 
UP request. The U-LSCF co-ordinates resources and activities needed to obtain data (e.g. Node B geographic co- 
ordinates) needed for the positioning method. It also records LCS RNC usage data for the location service request that 
may be passed to a Location System Recording Function (U-LSRF) or OA&M function in the Core Network. 
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If the positioning method requires the broadcast of system information, the LSCF initiates and maintains this activity 
through the Position Radio Co-ordination Function (U-PRCF). Broadcast information (such as the geographic co- 
ordinates of the Node Bs) may be required, for example, to support a Position Calculation Function (U-PCF) located in 
the UE. These broadcasts may also include other information (such as currently observable satellites) that may assist a 
UE in the use of external location services. 

The information to be broadcast is selected based on the positioning methods offered for use by the LCS and the needs 
of the UE. This broadcast information may be specially coded (i.e. encrypted) to ensure its availability only to 
subscribers of the service. The use of broadcasts or other methods for signalling to the UE or the LMU may be selected 
based on the chosen positioning method. 

The information to be broadcast could include, for example: 

identification and spreading codes of the neighbouring Node Bs (the channels that are used for measurements); 

Relative Time Difference (RTD), i.e. the timing offsets, asynchronicity between Node Bs, could be based on 
measurement results obtained by LMUs; 

- roundtrip delay estimates in connected mode; 

the geographic position, co-ordinates, of the neighbouring Node Bs; 

the idle period places within the frame structure for multiple Node Bs; 

the local time-of-day. 

Some of this information may be broadcast to support other UTRAN operations (e.g. handover). The function of the 
LSCF is to ensure information is broadcast when needed for the LCS operations and the LSCF may make use of other 
UTRAN processes to do so. 

B.2.2 UTRAN Location System Operations Function (U-LSOF) 

The UTRAN Location System Operations Function (U-LSOF) is responsible for provisioning of data, positioning 
capabilities, data related to clients and subscription (LCS client data and UE data), fault management and performance 
management of LCS within the RNC. 

An LSOF may be associated with each entity. The LSOF interacts with Internal (OAM) Clients for administration and 
maintenance of the data. 

The lur interface may pass messages relating to changes or reporting of the data associated with the LSOF in the RNC. 

The lub interface may pass messages relating to changes or reporting of the data associated with the LSOF in the Node 
B or the LMU. 

The Uu interface may pass messages relating to changes or reporting of the data associated with the LSOF in the UE or 
the remote LMU. 

B.3 Positioning group 

B.3.1 UTRAN Position Radio Co-ordination Function (U-PRCF) 

The UTRAN Position Radio Co-ordination Function (U-PRCF) manages a UP for a UE through overall co-ordination 
and scheduling of resources to perform positioning measurements. This function interfaces with the U-PSMF, the U- 
PRRM and the U-PCF. The U-PRCF determines the positioning method to be used based on the UP request, the QoS, 
the capabilities of the UTRAN, and the UE's capabilities. The U-PRCF also manages the needed radio resources 
through the U-PRRM. It determines which U-PSMFs are to be involved, what to measure, and obtains processed signal 
measurements from the U-PSMF. 

Some positioning methods may involve measurements made at the UE. In this case the U-PRCF interfaces with the UE 
to obtain the measurements (or the positioning results if they have been determined by the UE). Some positioning 
methods may involve measurements or information from several sources, including radio units at several Node B (or 
other LMU) and involve a series of transmissions and receptions. The U-PRCF entity also provide ancillary 
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measurements in case of network-assisted positioning method. Ancillary information may be extracted from navigating 
systems like GPS. 

The U-PRCF forwards the signal measurement data to the U-PCF. 

It is the function of the U-PRCF to co-ordinate the sequence of activities and compensate for failures (if they occur) to 
provide the position estimate. 

B.3.2 UTRAN Position Calculation Function (U-PCF) 

The UTRAN Position Calculation Function (U-PCF) is responsible for calculating the position of the UE. This function 
applies an algorithmic computation on the collected signal measurements to compute the final position estimate and 
accuracy. 

The U-PCF may also support conversion of the position estimate between different geographic reference systems. It 
may obtain related data (e.g.: Node B geographic co-ordinates) needed for the calculation. There may be more than one 
calculating function available within, or associated with, the calculation function of the UTRAN. 

In the cell ID based positioning method, the U-PCF shall determine the geographical co-ordinates corresponding to the 
cell(s) associated with the target UE. 

The PCF is also responsible for estimating the accuracy of the position estimate. This accuracy estimate should include, 
for example, the effect of geometric dilution of precision (GDOP), the capabilities of the signal measuring hardware, 
the effects of multipath propagation and the effects of timing and synchronisation unknowns. The accuracy should be 
returned as a measure of distance in the same units as the position estimate. The accuracy zone may be reported as the 
axis and orientation of an ellipse surrounding the position estimate. 

B.3.3 UTRAN Position Signal Measurement Function (U-PSMF) 

The UTRAN Position Signal Measurement Function (U-PSMF) is responsible for performing and gathering uplink or 
downlink radio signal measurements for use in the calculation of a UE position. These measurements can be positioning 
related or ancillary. 

There may be one or more PSMF within a UTRAN and they may be located at the UE, the Node B, or a separate LMU. 
The PSMF, generally, may provide measurement of signals (i.e. satellite signals) in addition to measurements of the 
UTRA radio transmissions. The measurements to be made will depend on the selected positioning method. 

B.3.4 UTRAN Position Radio Resource Management (U-PRRM) 

The UTRAN Position Radio Resource Management (U-PRRM) entity is responsible for managing the effect of LCS 
operations on the overall performance of the radio network. This may ensure, for example, that the operation of the U- 
PSMF does not degrade the QoS of other calls. The U-PRRM handles following functions: 

controlling the variation of the UL and DL signal power level due to the LCS application; 

calculating the DL and UL power/interference due to UE positioning operations; 

to admit/reject the new LCS requests; 

co-operating with Admission Control, and entities of the RRM (such as power control) to provide the system 
stability in terms of radio resources; 

controlling the RTD measurement mechanism. It may also forward the results of the RTD; ATD (or any similar 
timing parameter) measurements to the PRCF (or PCF); 

controlling the IPDL mechanism for positioning measurements. This may include the overall control of the 
periodical measurement fulfilment. Co-ordination among RNC (e.g. to assure non-overlapping idle periods) will 
be communicated through the lur interface. 
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B.4 Assignment of LCS Functional Entities to UTRAN Elements 

The figure B.l and the table B.l show the generic configuration for different positioning methods, including network- 
based, UE-based, UE-assisted and network-assisted methods. With this approach both UTRAN and the UE are able to 
measure the timing of signals and compute the UE position estimate. Depending on the applied positioning method it is 
possible to utilise the corresponding configuration containing all needed entities. For instance, if a network-based 
positioning method is applied, the entities that are involved in measuring the UE's signal and calculating its position 
estimate are allocated to the network elements of the access stratum. On the other hand, in case UE-based or network- 
assisted methods are used these entities should be allocated to the UE. 

Table B.l : Example Allocation of LCS Functional Entities to Network Elements 
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Annex C (informative): 
Location Services Categories 

Generally there are four categories of usage of the location service: 

- the Commercial LCS (or Value Added Services); 

- the Internal LCS; 

- the Emergency LCS; 

- the Lawful Intercept LCS. 

These location services categories are further defined in [1] and [4]. 
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Annex D (informative): 
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